Insecure Network Protocols: The Hidden Dangers

As missing patches are being deployed on time to prevent potential compromise, organizations are improving their security posture to avoid the most common threats from targeting them. However, a trend Packetlabs has noticed is that while exploiting systems directly is becoming more and more uncommon, the protocols in which the systems communicate with are susceptible to different types of attacks.

These vulnerable communication protocols allow attackers to masquerade as legitimate services resulting in the relaying and capture of authentication tokens and are all a result of using legacy or insecure services. Below are the four affected services we most commonly come across.

Insecure IPv6 Configuration

By default, all Windows versions above Windows Vista (including servers) have IPv6 enabled and prefer it over its IPv4 counterpart. On a network packet level, these Windows machines above Vista will request an IPv6 configuration via DHCPv6. This default IPv6 configuration allows an attacker to take over an internal network’s DNS by replying to the DHCPv6 packets.

Since an IPv6 configuration is preferred over an IPv4 configuration, the IPv6 DNS server will be the preferred DNS server. This configuration enables an attacker within the network to act as a rogue DNS server, which effectively acts as a proxy and would be able to redirect traffic. Furthermore, this misconfiguration allows attackers to leverage the Windows Proxy Auto-Discovery (WPAD) feature to relay the NTLM challenge and response and authenticate to various services and servers within the network.

Legacy Protocols: Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS)

Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) are two components of Microsoft Windows systems used as a backup when DNS is not able to resolve the user’s query. LLMNR was introduced in Windows Vista and is the successor to NBT-NS.

If one endpoint attempts to resolve a particular host, but DNS resolution fails, the machine will then attempt to ask all endpoints on the local network for the correct address via LLMNR or NBT-NS. Even though this seems harmless in theory, it enables an attacker to poison responses and performs various attacks to obtain unauthorized access to the network.

Insecure Server Message Block (SMB) Configuration

The Server Message Block (SMB) protocol in this environment was configured to use NTLMv1-2 (NT LAN Manager) for authenticating users accessing file shares. NTLM is a challenge/response authentication protocol designed in the 1990s as a replacement for older LAN Manager authentication. While NTLMv2 provides improvements over NTLMv1, both versions are inherently vulnerable when compared to modern standards like Kerberos or certificate-based authentication.

The main weakness lies in the lack of mutual authentication and reliance on predictable challenge/response sequences. This opens the door for man-in-the-middle (MitM) and relay attacks. In such scenarios, an attacker who can intercept or capture network traffic can insert themselves into the authentication exchange. Rather than needing to crack the challenge/response, the attacker can relay the captured authentication data to another server in real-time. This technique is known as an NTLM relay attack.

From the attacker’s perspective, this is particularly dangerous because it allows them to impersonate a legitimate user without knowing their password. If the relayed credentials belong to a privileged account—such as a domain administrator—the attacker could gain unauthorized access to critical systems, file servers, or domain controllers. This compromises not just a single host but potentially the entire network.

NTLM authentication is also susceptible to credential replay and offline cracking. Since NTLM hashes are relatively weak compared to modern hashing algorithms, once captured, they can often be brute-forced or cracked using tools like Hashcat. Furthermore, NTLM does not inherently enforce strong encryption or session integrity, allowing attackers to manipulate sessions once authenticated.

Why This is Dangerous

• Relay Attacks – Attackers can reuse captured authentication requests to authenticate against other systems.

• Privilege Escalation – If a privileged credential is captured and relayed, entire domains could be compromised.

• Credential Theft – Captured NTLM hashes can be cracked offline to reveal cleartext passwords.

• Weak Protections – NTLM lacks protections like mutual authentication and robust encryption present in Kerberos.

Insecure Kerberos Deployment

Kerberos is a ticket-based authentication protocol. Windows has implemented a Kerberos authentication service that is built into Active Directory. Any domain user possessing a Kerberos ticket-granting ticket (TGT) may request ticket-grant service (TGS) tickets for any accounts with Service Principal Names (SPNs) from a domain controller. When a TGS is requested for an SPN by a user the TGS is granted to the user, as long as they have a valid TGT. This does not allow the user possessing the TGS to access the service; the service determines if the requesting user has authority.

However, the TGS contains some data that is encrypted by the SPN account’s NTLM hash. This data can be used in a password cracking attack to reveal the plain-text password of the service account. Microsoft does not consider this a vulnerability: as a result, special attention and configuration of accounts with SPN values are required.

Remediation

Remediation for each affected service must under-go testing before deploying to production as some of the services are needed on legacy systems. For example, NetBIOS or LLMNR is required for Windows 2000 and earlier. Below are the quick remediation steps for each of the four affected services.

• IPv6 – If it is not being used, disable IPv6

• Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) – disable LLMNR and NetBIOS where possible

• Server Message Block (SMB) – enable SMB signing on all workstations and servers

• Kerberos – Regularly monitor accounts to ensure only services requiring Kerberos authentication have a non-null SPN value. Use AES encryption instead of RC4 for Kerberos services. For SPN enabled accounts, use a 25 character or greater password

At Packetlabs, we specialize in assessing and exploiting networks using insecure protocols. If you need assistance with evaluating your network for these protocols, contact us for an assessment.